For security purposes, many communications need to be secure (e.g., encrypted). Some communications, for example, for exchanging information between a client and a server, should be encoded in such a way that only the intended recipient should be able to receive the information. Traditionally, a public key infrastructure (PKI) can be used to create secure communications between a client and a server. PKI uses digital certificates that include information (e.g., a public key) that can be used to encrypt data. An entity (e.g., a server) that provides a service (e.g., a web application) can be issued a private key and a corresponding public key for the service. The public key can be included in a digital certificate that can be shared, for example, with a client. The client can use the service's public key to encrypt data and send the encrypted data to the server. The server can decrypt the received data using the service's private key.
When a client receives a digital certificate and public key, for example, from a server, the client generally first determines whether the client can trust that the digital certificate is indeed identifying the service in order to avoid a man-in-the-middle attack. A man-in-the-middle attack generally involves a malicious party that pretends to be the service which a client is trying to communicate with. For example, John Doe may use a client (e.g., a web browser) to log on to his bank's homepage www.bank.example to do online banking. John Doe may attempt to access www.bank.example, but the communication between the web browser and the bank's server providing the service may be intercepted and hijacked, and a malicious party that pretends to be the bank website can send a false bank web page to the web browser. The false bank web page can present a fake public key to the web browser. John Doe may input personal data into the false bank web page, and the web browser may use the public key to encrypt the personal data and submit the personal data to the malicious party.
To prevent man-in-the-middle attacks, a server (e.g., bank server) generally obtains a digital certificate for the service from a conventional third party top-level certificate authority. A traditional certificate authority (CA) is typically a third party organization that stores public keys and corresponding owner information, and is generally trusted by every party (e.g., web browser) in a communication. The parties are aware of the CA's public key.
An applicant (e.g., bank server) can send a request for a digital certificate to a remote third party CA. Prior to signing a digital certificate for an applicant (e.g., a bank server), a traditional CA typically performs various functions to verify an applicant's credentials to allow relying parties (e.g., web browsers) to trust the identity of the applicant and information in the digital certificate that is signed by the traditional CA. When a conventional CA has verified the identity of the applicant, the CA signs the digital certificate for the applicant (e.g., bank server) using the private key of the CA, and sends the digital certificate of the applicant (e.g., bank server) to the applicant, which the applicant can send to clients.
The CA has its own digital certificate (e.g., CA certificate) that includes the public key of the CA. The third party CA distributes its CA certificate to remote clients (e.g., web browsers). The clients that trust the remote third party CA can store the CA certificate in the client's trust store. When a client (e.g., web browser) receives a digital certificate for a service from a server (e.g., bank server), the client can determine that the signature of the digital certificate of the service corresponds to the CA certificate that the client has stored in its trust store. The client can use the information in the CA certificate to validate the identity of the service and trust that the public key that is received for the service can be used to create secure communications.
A digital certificate that is received from a traditional CA is generally expensive and can take a significant amount of time for the conventional CA to verify the identity of the applicant. In some scenarios, secure communications may be needed, but a digital certificate from a traditional CA cannot be obtained, for example, due to costs and/or time. For example, web application developers may wish to test a web banking application communicating with a client in a development, staging, and/or testing environment, and may not have the time or budget to obtain a digital certificate for the web banking application from a remote third party trusted CA.
Some developers may use a conventional self-signed certificate for development, staging, and/or testing purposes. Traditionally, a self-sign certificate is an identity certificate that is signed by the same entity whose identity it certifies. A developer usually generates a digital certificate for the web banking application, and rather than have a third party remote CA use the private key of the CA to sign the digital certificate, the web developer uses the private key of the web banking application to sign the digital certificate for itself. The web banking application acts as its own signing authority. Generally, the result is that no client (e.g., web browser) will trust a self-signed certificate because the client typically does not have a digital certificate for the web banking application in its trust store.
Some clients may manually add specific digital certificates that correspond to the signing authorities for self-signed certificates to a trust store. The manual addition of such specific digital certificates to the trust store, however, is vulnerable to man-in-the-middle attacks. For example, a malicious party may gain access to the digital certificate of the web banking application, and can use the digital certificate to sign digital certificates for any other malicious service. The clients that have the comprised digital certificate in its trust store would then automatically trust any digital certificate that was signed using the comprised digital certificate.